VS2013 2015 2017 新建默认UTF

HTML有charset属性，XML有encoding属性，没必要拉BOM撑场面

UTF-16这种编码连ASCII都双字节，实在不适用于做网页

通常BOM是用来标示Unicode纯文本字节流的，让文本处理程序识别txt文件是哪个Unicode编码（UTF-8，UTF-16BE，UTF-16LE）

Windows相对对BOM处理比较好, 打开文本文件时它会自动识别并剔除BOM.

Windows的设计者希望能在用户不注意的情况下同时兼容Unicode和非Unicode（Multiple byte）文本文件.

Linux一步到位进入UTF-8, 过渡期至少经历了三到四年.

BOM不受欢迎主要是在UNIX环境下，因为很多UNIX程序不鸟BOM。因为BOM本身违反了一个UNIX设计的常见原则，就是文档中存在的数据必须可见。

UNIX环境下我们还有VIM这种神器，即使遇到BOM挡道，我们也可以通过 set nobomb; set fileencoding=utf8; w 三条命令解决问题。

似乎也真就只有Windows坚持用BOM了。

UTF-8不需要BOM, 所以不含BOM的UTF-8才是标准形式.

微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开

UTF-8 的网页代码不应使用 BOM，否则常常会出错

写C++代码建议程序要在windows 和 mac 还有linux 上运行的话，源代码最好保存成utf-8 带bom的格式，这样比较通用一些。而用utf-16 无论大端还是小端，g++ 都不认的。或者用utf-8 不带bom格式，然后代码不要出现非ascii 127以后的字符。

带用bom的utf-8也是符合国际标准的

微软在坚持使用bom上没有错，因为这是在为用户考虑的。也许给我们这些写程序的带来了不便，但是，计算机最广泛的用户不是程序员。

带头的鹅和去头的鹅，有些编辑器比较傻会把去头的鹅认成鸭子

以UTF-8格式编码, 从notepad++ --> Mongodb里面复制东西的时候，莫名其妙多了不少的字节数。如果不安装notepad++，使用默认的记事本，那就更是个坑，默认有bom，你还无法选择。

就是因为这个bom，CSV导入mongodb时，第一个字段总是不正常，直接导致用第一个字段作为条件find时，出不了结果!

utf8对ascii的兼容确实是它的好，但是这个优点在某些时候恰恰成了隐藏问题的缺点。因此bom大法好，加bom保平安.

为什么windows的记事本要强行给utf8加bom的原因——为了兼容旧系统的编码问题，unix阵营放弃带bom的utf8——为了让它们的上古程序能继续运行下去，这个各自有自己利益诉求的差异决定其实并不对错